Skip to content

Deprecations and removals in CAP Java 5#2479

Open
StefanHenke wants to merge 4 commits intomainfrom
deprecations-removal-cap-5
Open

Deprecations and removals in CAP Java 5#2479
StefanHenke wants to merge 4 commits intomainfrom
deprecations-removal-cap-5

Conversation

@StefanHenke
Copy link
Copy Markdown
Contributor

Added sections for adjusted, deprecated, and removed properties, as well as removed Java APIs in migration documentation.

Added sections for adjusted, deprecated, and removed properties, as well as removed Java APIs in migration documentation.
@StefanHenke StefanHenke marked this pull request as ready for review April 8, 2026 12:30
@StefanHenke StefanHenke requested a review from smahati as a code owner April 8, 2026 12:30
@StefanHenke StefanHenke enabled auto-merge (squash) April 8, 2026 12:30
Added migration details for UCL methods and updated deprecated method
replacements.
Comment thread java/migration.md

- `abd`

The functionality provided by these properties is enabled by default and there is no reason to switch these off.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence sounds as if we ask the user to not switch off a deprecated property, or? Isn't the exact opposite the case?

Copy link
Copy Markdown
Contributor Author

@StefanHenke StefanHenke Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renejeglinsky : I basically copied this sentence over from the previous migration guide. The meaning behind is: Typically, these deprecated properties can be used to toggle a newly introduced or incompatible feature. After some time, we enable these features by default and deprecate the corresponding property. This still gives applications in worst case (safety net) the possibility to switch off the features in the current release. This might give some time for adapting to the new behavior. However, once the property is deleted in the next major, it cannot be switched off anymore and applications have to live with the new feature behavior. That´s why the properties should not be switched off. Maybe only after our explicit recommendation for concrete stakeholders.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, is there Is a significant difference between switching it off and not using it. Switching off would mean to not use the new default whereas not using it (that is, delete the property, right?) would mean using the default.
I haven't considered to use it to switch off default behavior.

Suggested change
The functionality provided by these properties is enabled by default and there is no reason to switch these off.
The functionality provided by these properties is enabled by default. If you enabled and tested it already and want to use the default, you can safely remove the property. If you want to stay with the previous behavior und start testing the new default now, you can set it to `false`.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment thread java/migration.md

- `abd`

The functionality provided by these properties is enabled by default and there is no reason to switch these off.
Copy link
Copy Markdown
Contributor Author

@StefanHenke StefanHenke Apr 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@renejeglinsky: With new default (activated), stakeholders will automatically test the new behavior. Only if they face issues, they might get back to the previous behavior by setting it to false which we, however, strongly discourage. That´s why I wouldn´t mention this here.

What about:

Suggested change
The functionality provided by these properties is enabled by default and there is no reason to switch these off.
The functionality provided by these properties is enabled by default. This reflects its intended behavior once the properties are deleted in future releases.

…ide (#2481)

## Summary

- Adds 5 OpenRewrite recipes for `ServiceExceptionUtils` method removals
to the Currently Released CAP Java Migrations table
- Documents removed `ServiceExceptionUtils` methods and their
replacements in the `Removed Java APIs` section of the CAP Java 4.9 →
5.0 migration guide

## Test plan

- [ ] Verify recipe table links (`#service-exception-utils-removals`)
resolve correctly
- [ ] Verify removed method signatures and replacement calls are
accurate

---------

Co-authored-by: Stefan Henke <stefan.henke@sap.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants